AD- A110  122  6E0R6I A  INST  OF  TECH  ATLANTA  F/6  5/5 

COMPUTER  AIDED  SPECIFICATION  TESTIN6  SYSTEM  (CASTS).  VOLUME  III— ETC(U) 
MAR  81  D  E  HUMPHREY.  D  P  MILLARD  D A AK 70 -79-0-0087 

NL 


UNCLASSIFIED 


SECURITY  CLASSIPICATtON  O P  THIS  PAGE  fETil  Data  Bnltrtd) 


REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1.  REPORT  NUMBER  2.  GOVT  ACCESSION  NO. 

•H'.-  •  i  ' 

2.  RECIPIENT'S  CATALOG  NUMBER 

"(  iv 

«.  TITLE  (tnd  Submit) 

CASTS 

(COBOL  PROGRAMMING  CONVENTIONS) 

TYPE  OP  REPORT  *  PERIOD  COVERED 

R$D  Technical  Report  Final 

PERPORMINO  ORG.  REPORT  NUMBER 

V.  AUTHORft) 

D.  E.  Humphrey,  D.  P.  Millard 

EES,  Georgia  Institute  of  Technology 

B.  dONTRACT  OR  GRANT  HUMBERT*} 

DAAK70-79-D-0087 

Task  Order  Number  0007 

S.  PERPORMINO  ORGANIZATION  NAME  AND  ADDRESS 

Georgia  Institute  of  Technology 

Atlanta,  Georgia  30332 

i|g|i|||| 

11.  CONTROLLING  OPPICE  NAME  ANO  ADORESS 

US  Army  Institute  for  Research  in  Management 
Information  and  Computer  Science 

115  O'Keefe  Bldg.,  GIT  n 

Atlanta,  Georeia  30332  '  J 

12.  REPORT  DATE 

15  March  1981 

IS.  NUMBER  OP  PAGES 

26 

14.  MONITORING  agency  NAME  S  AOORESSf//  dt  Iterant  tram  CentralUnd  Otttam) 

IS.  SECURITY  CLASS,  (at  Me  report) 

Unclassified 

mhhh mm 

IS.  DISTRIBUTION  STATEMENT  (at  thlt  Report) 

Approved  for  public  release,  distribution  unlimited. 

17.  DISTRIBUTION  STATEMENT  (at  Ota  tbttrtct  entered  In  Black  20,  If  dlttarant  from  Report} 

Same 

IS.  SUPPLEMENTARY  NOTES 

19.  KEY  WORDS  (Continue  on  rtmN  cidm  tf  ntcftMry  and  1  dan t tty  by  black  number) 

Computer-Aided  Design,  Man-Machine  Interface,  Human  Factors,  Specification 

Testing,  Interactive,  Data  Entry. 

SO.  ABSTRACT  fCaatfeu*  am  ravaraa  N*  IT  tier aaaaatr  and  tdantltr  Sr  block  mombar) 

■The  Computer  Aided  Specifications  Testing  System  (CASTS)  is  a  tool  to  aid  in  the 
design  of  interactive  systems.  It  is  concerned  with  human  factors  and  the  man- 
machine  interface  during  the  initial  capture  of  data  and  the  editing  of  that 
data.  CASTS  is  divided  into  two  processes.  The  first  process  is  that  used  by 
the  designer  to  construct  simulations  of  interactive  video  display  terminal 
dialogue;  the  second  process  gathers  the  performance  data  of  an  actual  user  who 
runs  the  simulation  designed  in  the  first  process. 

DO  UMTS  W73^  COITION  OP  I  NOV  ••  It  OOCOICTC  ±  M  #0  0  *  Ci 


SECURITY  CL Attl  PIC ATtON  OP  this  PAGE  (1W>n  Om<  Enfarwo 


COBOL  programming 
CONVENTIONS 


Accession  For 
NT IS  GRA&I 

dtic  tab 

Unannounced 

Justification. 


PIC 

/.v; 


;/ 


□ 


'’ories 
.  /'or 


Prepared  bv 

Computer  Science  and  Technoloov  Laboratory 
Enalneerlno  Experiment  Station 
Georaia  Institute  of  Technoloov 
Atlanta,  Georaia  30332 


0.  E.  Humphrey 


AIRMICS 

Georaia  Institute  of  Technoloov 
Room  325.  Hlnman  Research  Bulldino 
Atlanta,  Georaia  30332 


Under  DAAK70-79-D-0087.  Tasit  Order  0007 


PAGE  2 


SABLE  QE  COBXEBZS 

0.0  Introduction 

l.O  Programming  considerations 

2.0  Conventions  Throuohout  a  Program 

3.0  Identification  Division 

4.0  Environment  Division 

5.0  Data  Division 

6.0  Procedure  Division 

Appendix  a  -  Acknowledgements 
AoDendlx  8  -  Example  Program 

Index 


Suoersesslon/UDdate  Information! 

This  is  a  new  document,  version  0.  wav  29.  1980 


iiixaaouczioii 


Motivations  for  the  deslan  of  the  oroarammlno 
lanauaae,  COBOL,  Included  achlevlno  a  common  standard 
lanauaae  and  lmDrovlna  the  readability  of  source  pro- 
crams.  COBOL  has  certainly  enloved  widespread  applica¬ 
tion.  but  the  opportunities  for  clarity  and  readability 
of  oroarams  are  often  nealeeted.  This  document  speci¬ 
fies  a  set  of  oroarammlno  conventions,  emohesizlna 
COBOL  codlno  practices,  for  use  In  wrltlno  oroarams 
which  are  easy  to  understand  and  to  maintain. 

The  Droaremmlna  conventions  described  herein  at¬ 
tempt  to  embodv  the  concepts  of  structured  proorammlna, 
consistency.  understandabllltv  and  readability. 
Steowise  refinement  and  too-down  development  ao  hand  In 
hand  with  structured  oroarammlno  and  modularity.  They 
should  be  reflected  In  both  the  final  coded  oroaram  and 
the  auldellnes  for  codlna  that  oroaram.  Thus,  the  con¬ 
ventions  Include  such  thinas  as  a  consistent  Indenta¬ 
tion  scheme,  the  use  of  meaninaful  date  and  oaraaraoh 
names  and  the  avoidance  of  nonstandard  features. 
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1.0  BfiflfifiAMMXIIfi  C0051DE8AXZDN3 


1.1  Notes  on  Proaram  Deslan 

Tha  followlna  notes  should  be  taken  into 
consideration  durina  the  desian  onese  of  orooran 
develoDment.  The  Idea  to  keep  in  mind  is  ciarltv. 
Sav  what  is  meant.  simolv  and  directly. 
Generally,  all  oroarams  should  be  structured  so 
that  thev  are  readable,  loaieallv  efficient  and 
easily  maintained.  Choose  a  data  reoresentation 
that  makes  the  oroaram  simple,  modularize  the 
oroaram  structure.  Each  module  should  do  one 
thina  well.  Bad  code  should  be  rewritten,  not 
notched. 

Top-down  structured  oroaram  desian  lends  it¬ 
self  to  a  hierarchical  oroaram  structure.  The 
suaaested  accroach  is  to  consider  the  overview  of 
the  oroaram  function  as  a  "zero  level”  routine  (or 
oaraaraoh).  This  corresponds  to  the  root  of  a 
tree.  Consider  each  function  in  turn.  On  a  VTOC 
(Visual  Table  of  Contents)  dlaaram  this  would  be 
araohleallv  oraanlzed  from  left  to  rloht.  At  each 
level,  each  function  can  be  further  broken  down 
into  its  components  until  a  primitive  function 
level  is  reached,  (see  dlaaram) 
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000 


200 


Examole  VTOC 


Incut  and  output  should  be  olanned  careful¬ 
ly.  Test  Inout  for  validity  and  oiausibilltv. 
Ensure  that  inout  cannot  violate  orearam  limits  or 
eause  an  abnormal  endlna.  Terminate  in;?ut  bv  an 
end-of-file  mark,  not  bv  a  count.  Identify  bad 
inout  and  recover  if  possible.  Finally,  localize 
inout  and  outout  in  order  to  facilitate  debuaalno 
and  future  maintenance. 
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Code  runs  fester  and  is  easier  to  read  and 
understand  If  It  is  compact.  Replace  repetitive 
expressions  bv  a  oaraaraeh  that  mav  be  performed 
when  needed.  However,  don't  strain  to  re-use 
codet  reoraanize  instead.  Make  sure  special 
eases  are  truly  special.  Keep  the  proaram  simple 
to  make  it  faster.  Make  it  riaht  before  makina  it 
taster.  Keep  it  riaht  when  makina  it  faster. 
Don't  sacrifice  elaritv  for  small  aains  in  "effi¬ 
ciency". 

Documentation  is  verv  important  in  orovldina 
maintainability.  In-line  documentation  means  more 
than  lust  a  few  comments.  It  can  be  the  most  use¬ 
ful  form  of  documentation  with  minimal  effort. 
First,  make  sure  comments  and  code  aoree.  Do  not 
lust  echo  the  code,  make  comments  count.  Don't 
comment  bad  co del  rewrite  it.  And  don't  over 
comment.  In-line  documentation  also  entails  uslna 
meanlnaful  variable  names  and  paraaraoh  names,  in- 
dentlna  to  indicate  loolcal  proaram  structure  and 
formattlna  to  help  the  reader  understand  the  pro¬ 
aram. 

1.2  Terminal  Format  vs.  Conventional  Format 

All  of  the  auldellnes  for  conventional  for¬ 
mat  apply  eauallv  well  to  terminal  format  pro- 
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arams.  Onlv  two  differences  need  be  pointed  out. 
First,  since  there  are  no  columns  for  seouenclno 
In  terminal  format,  all  conventions  referrlno  to 
column  8  translate  to  column  1.  and  likewise  co¬ 
lumn  12  to  column  5.  Second,  the  comment  Indica¬ 
tor  (*)  should  be  Placed  In  column  1. 


i 
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2.0  COlUtEMXiattS  XMBQUCHQUX  l  EIQfiSU 


2.1  Comment  lines. should  be  ys.ed  in. ell  sections  where 
9  eoneeot  .mlaht  need  exoiepetion  other  then  whet 
Is  evident  in  the  COBOL  code.  Normally,  however, 
well  chosen  dete  end  oereareoh  nemes  should  eonvev 
the  meenlna. 

2.2  Comment  lines. should  be  used  to  document  cells  to 
externel  routines. 

2.3  Division  heeders  end  oereareoh  heeders  beam  In 
column  9. 

2.4  indentations  .successive  levels  of  indentation 
win  consist  of  4  soeees. 

2.5  L}ne  soeclnat  soeee  3  blank  lines  before  a  divi¬ 
sion  hfeder.  .2  lines  before  a  section  header,  l 
line  b9f ore  e  oereareoh  header.  1  line,  betyeen 
arouo  Items  .in  the  Dete  Division  end  no  line  after 
the  oereareoh  header  end  before  the  oereareoh 
bodv. 

2.6  Aithouah  wprds  may  be  broken  off  end  continued  on 
the  next  line,  this  should  be  avoided  for  the  sake 
of  reedabllltv. 
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3mQ  IDEMXEICAIIQII  DIVISION 


3.1  Should  contain* 

PROGRAM-ID. 

AUTHOR. 

INSTALLATION. 

DATE-WRITTEN. 

DATE-COMPILED. 

REMARKS. 

3.2  PROGRAM-ID  Is  Che  firs$  sentence  end  .should  be 
preceded,  bv  2. blank  lines.  The  name  oiven  as. the 
proaram  Identifier  is  the  same  as  the  source  file 
name. 

3.3  The  author  is  the  oroorammer  who  orlalnallv  coded 
the  Droaram. 

3.4  The  DATE-WRITTEN  is  the  date  codlna  beaan. 

3.5  DATE-COMPILED  slonals.the  comoller  to  orint  the 
date  on  the  Droaram  listina. 

3.6  The  remarks  oaraareph. 

3.6.1  Form. 

3. 6. 1.1  All  remarks  lines  have  an  asterisk 
(♦)  in  column  7. 

3. 6. 1.2  Place  each  remark  on  lt$  own. line, 
indentino  anv  continuation  lines  4 
soaees. 

3. 6. 1.3  Three,  types  of  remarks  are  1) 
functional.  2)  additional  and  3) 
modlf ieational.  Each  oroup.  is 
separated  bv.one  blank  line  (*  in 
column  7).  with,  no  blank ..  lines 
amona  remarks  within  a  arouo. 

3.6.2  Functional  rfmarks  appear  first  and  contain 
the  application. project  name  and  e  brief 
description  of  mbai  the  broaram  does. 

3.6.3  Additional  remarks  are  second,  if  appropri¬ 
ate.  and  include  such  thinos  as  subroutines 
referenced,  library  modules  referenced 
(COPY  or  CALL  modules)  and  oroaram 
switches. 
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3.6.4  Prooram  modification  remarks. 

3. 6. 4.1  Each  modification  line  has  the 
fgrm:.  *kOD*  yy/km^OD  -.text.linp, 
with  indented  continuation  lines. 

3. 6. 4. 2  These  remarks  assist  in  tracklno 
down,  .maintenance  .debug  errors, 
providing  modification  history  do; 
eumentatjon.  Thev  should  be  brief 
and  concise. 
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4.A  ElUfXBflKXENX  DIVISION 


4.1  Leaye.3  blank  lines.  between  .the.  Zdentlf leatlon 
Dlvlflon  and  the  Environment  Division  header  and  2 
blarjk  lines. after  the  header,  before  the  Confiau- 
ration  Section. 

4.2  Division  header.,  section  names  and  oaraoraohs 
beoln  in  column  8. 

4.3  Should  contain! 

ENVIRONMENT  DIVISION. 

CONFIGURATION  SECTION. 

SOURCE-COMPUTER, 

OBJECT-COMPUTER. 

INPUT-OUTPUT  SECTION. 

FILE-CONTROL. 

<file  SELECT  statements> 

4.4  SELECT  statements. 

4.4.1  Each. SELECT  statement  is  separated  from  the 
previous  statement  bv  one  blank  line. 

4.4.2  Place  the  SELECT  and  ASSIGN  clause;  09  t£e 
same  line  whenever  possible,  bealnnlna  in 
column  12. 

4.4.3  Place  additional. clauses  on  separate  lines, 
lndentlna  each  line  to  column  16. 

4.4.4  Suaaes$ed  order  for  SELECT  statement;,  is 
a$cordlna  to  order  of  usaae  of  the  files 
within  the  orooram.  An  alternative  oyder- 
ina  is  listina  the  most  active  files  first. 


i 
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5.1  Lpave  3  blank  lines  between, the  environment  Divi¬ 
sion  and  the  Data  Division  header  and  2  plank 
lines  after  the  header,  before  the  first  section. 

5.2  Division  header*  section,  names*  paragraphs*  FPs 
and  level  01  data  descriptions  beoin  in  column  §. 

5.3  FD  declarations. 

5.3.1  Precede  FDs  with  one  blank  line. 

5.3.2  Leave  2  spaces  between  "FD"  and  Its  file 
name. 

5.3.3  FDs. should  appear  In  the  same  order  as 
their  corresponding  SELECT  statements. 

5.3.4  Additional  FD  clauses  beoin  on  separate 
lines,  indented  to  column  12. 

5.3.5  Those  file  descriptions  that  are.  permanent 
op  are  used  more  than  once  w£thin  a  pvstem 
of  programs, should  be  stored  in  a  library 
and  cooled  Into  the  programs. 

5.4  Data  description  level  numbers. 

5.4.1  Ppeepde  all  level  01  numbers  with  one  blank 
line. 

5.4.2  Lpvei  numbers  subordinate  to  01  are  as- 
slaned  in  increments  of  1  (except  08). 

5.4.3  Leave  2  spaces  between  a  level  number  and 
Its  data  name. 

5.4.4  Level  0 J  descriptions  beo|n  in  column  8» 
Successive  levels  erp  Indented  4  spaces. 
After  level  02*  indenting., oplv  2  spaces  Is 
allowed  If  andoniv  if  multiple  level  spac¬ 
ing  becomes  a  problem. 

5.5  Allan  all  PICTURE  clauses  In  one  eolumn.  Allan 
VALUE  and  USAGE  clauses  as  mueh  as  possible. 


5.5.1  Tpe  value  clause  should  appear  pn  jne  same 
line  as  the.  PZCTyRE  clause.  If  It  is  thp 
first  clause  following  the  PICTURE  clause. 
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If  the  value  to  be  assloned  is  twelve  char- 
eeters  Iona  or  less.  It  should  also  , oo  on 
the  sane  line.  .Lonoer  values  continue  on 
the  next  line  indented  the  standard  4 
spaces. 

5.6  Use  meanlnoful  data  names,  (see  4.10.3  also) 

EX.  RANGE-BOUNDS 
REPORT-TITLE 

5.7  Use  PIC  $.  instead  of  PIC  A.  for  areater  UDdate 
flexibility. 

5.8  When  deflnlra  conftants  with  lenothv  VALUE  liter- 
fls  such  as  heaglnas.  u§e  severe}  elementeyv  ,da$a 
Items  to  sub-deflne  the  Item.  This  will  simplify 
maintenance,  particularly  when,  a  report  myst  be 
adlusted  to  add  an  element  or  alien  the  headlno. 

5.9  use  FILLER  for  anv  data  item  notejolicitjv  refer¬ 
enced.  unless  the  Item  description  is  in  a  COPY 
module. 

5.10  Worklna  fltoreae  Section. 

5.10.1  ^evei  77  items  are  not  allowed,  use  01 
items. 

5.10.2  Variables  with  similar  functions  should  be 
arouded  toaether  under  level  Oi  data  names. 

EX.  CONSTANTS  POINTERS 

COUNTERS  SWITCHES 

FLAGS  anv  tables 

MESSAGES 

5.10.3  Namlna  conventions  for  level  01  arouos. 

5.10.3.1  Counters  should  end  in  "-CTR"  or 
"-CNT" . 

5.10.3.2  Messaae  .data  items  should  have 
"-MSG”  appended  to  them. 

5.10.3.3  Pointers  should  end  in  "-PIR*. 

5.10.3.4  Switches  should  end  in  "-SW".  and 
should  have  level  88,  condition 
names  assioned  for  testina. 


EX.  02  EOF-SW  PIC  9  VALUE  0 
88  EOF  VALUE  1 
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6.fl  BBOCCSUAC  DIVISION 


6.1  Leave  3  blank  lines. between  the  Date  Division  .and 
the  Procedure  Division  header  and  2  blank  lines 
after  the  header,  before  the  first  section. 

6.2  The  division. header*  section  names  and  oaraareoh 
names  beoin  in  eolumn  8. 

6.3  There  should  be  ag  GOTO  statements!  There  is  only 
one  exception),  in  the  input  and/or  OUTPUT  proce¬ 
dure  sections  of  a  SORT.  and. then  there  should  be 
oniv  one  to  branch  to  the  exit  baraoraoh. 

6.4  Modular  Proaram  Structure. 

6.4.1  A  module  refers  %o  a  unit  of  code.thati.  1) 
has  one  entrv  point.  2)  has  one  exit  oo|nt« 
3)  has  one  functign.end  4)  can  be  refer¬ 
enced  bv  an  identifier  as  a  unit.  In  other 
words  a  module  is  usuailv  a  paraopaoh.  but 
can  also  be  construed  as  a  section  or  su¬ 
broutine. 

6.4.2  a  orooram  should  contalpr 

Ma|n. line  rgutlne 
Initialization  routine 
Processing  modules 
Input/Outout  routines 
End  of  lob  routine 

6. 4. 2.1  The  main  line  routine  shguld  be 
the  hiahest  level  executive  con- 
trollina  oaraareoh  for  the  .oro- 
oram.  it  causes  all  other  oara- 
areohs  to  be  .performed  and  it 
should  have  little  or  no  condi¬ 
tional  loaie. 

6.4. 2.2  The  initialization  takes,  care  of 
the  ",se$tino..up"  functions,  such 
as  ooen|ng  fi|es.  cettinc  the 
date,  inltielizlno  variables*  etc. 

6. 4. 2. 3  Processing,  modules  snouio  eaeh 
perform  asm  function,  reflected  bv 
the  module  name. 

6. 4. 2. 4  inout/Outout  routines  contain  all 
reads,  writes  and  rewrites  for 


each  flic  and  ara  orouoed  tooth¬ 
er.  .There  should  ba  only  one  ear- 
aoraph  |n  th$  prporam  for  each  gt 
these, .functions.  Maintenance  is 
simplified. bv  eentralizino  dlraet 
I/O  operations. 

6. 4. 2. 5  The  end  of. lob  routine  should. per¬ 
form  closlna  "housekeeolno"  func¬ 
tions.  such  as  elosina  files*  oro- 
eessinq  last  raeords  and  and  of 
report  routines. 

6.4.3  Module  Namlno  Conventions. 

6. 4. 3.1  Each  module  (oaraoraohor  spctionj 
name  .consists  of  two  oartsi.  1}  a 
3  dioit  number,  2)  a.  meaninoful 
name.  This  is  . helpful  from  the 
prooram  deslon. phase  throuqh  test- 
inq  and  deyuooino,  documentlnq  and 
finally  maintenance. 

6. 4. 3. 2  The  dioit  ogrtion  of  a  module  name 
if  .indicative  of  the  module's  .po¬ 
sition,  both  loolcallv  In. the  prg- 
qram  hierarchy  and  physically  in 
the  coded  .orooram.  .  Modules  .are 
arranqed.  in  ascendino  numerical 
order,  with. the  controllino  main 
routine  beinq  "000".  They  shoyld 
reflect  a  tree-like  structure  with 
levels. 

6. 4. 3. 3  within  the  same  prooram,  verbs 
used  in  module  names  ouoht  to  have 
the  same  meanlno. 

6.5  One  blank  line  separates  each  paraoraoh  body  from 
the  followino  header. 

6.6  each  statement  should  appear  on  a  separate  line, 
ng  multiple  statement  lines.  This  enhances  reada¬ 
bility  and  update  ease. 

6.7  rour  spaces  ara  used  for  loole  level  indentation. 

6.8  Statement  formats. 

6.8.1  If  a. statement  is  loncer  .than  one  line, 
continue  on  successivf  lines  at  the.  start 
of  a  clause  or  Phrase,  lndentlne  4  spaces. 
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EX.  PERFORM  <oaraaraon  name> 

UNTIL  <cendlt|oni> 

AND  <condition2>. 

6.8.2  In  statements  fueh  as  OPEN.  CLOSE  and  sona¬ 
tinas  MOVE*  similar  elements  should  be  al¬ 
iened,  l.e.  file  and  data  names. 

EX.  OPEN  INPUT  OLO-MASTER-riLE 

UPDATE-PILE 

OUTPUT  NEW-MA8TEP-FILE 

ERROR-REPORT-FILE. 

EX.  MOVE  2ER0  TO  LINE-CNT. 

MOVE  SPACES  TO  PRINT-LINE. 

MOVE  PART-INFO  TO  PRINT-PART. 

6.8.3  IF  statements. 

6. 8. 3.1  Put  the  IF  and  ELSE  (if  there  Is 
one)  on  seoarate  lines  from  the 
Indented  statements. 

EX.  if  <condltlon> 

<statement> 

ELSE 

<statement>. 

6. 8. 3. 2  Nested  IF  statements  are  also  In¬ 
dented.  _  if  there  are  more  than  5 
levels  of  nested, jFs*  re-evaluate 
the  orooram  deslan.  The  levejf 
mav  be  indented  qn}v  2  soa$es  If 
neeessarv  to  Keen  from  runnlna  out 
of  eodina  soaee. 

6. 8. 3. 3  For  the  IF  statement  used  _ln  a 
"ease"  structure,  the  next  IF 
should  aooear  on  the  same  line  as 
the  ELSE  and  all  ELSEs  should  be 
alianed. 

EX.  IF  <eondltlonl> 

<statemen|l> 

ELSE  IF  <eondltlon2> 
<statement2> 

ELSE 

<statement3>. 

6.9  Comoound  conditions. 

6.9.1  |n  comoound  conditions,  use  parentheses  to 
indicate  the  order  of  evaluation. 
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6.9.2  Allan  similar  Darts. 

EX.  IP  <condltionl> 

OR  <condltion2> 

OR  (<condition3>  AND  <cendltlon4>) 
<stetement>. 

6.10  Often  used  literals  should  oe  defined  as  eon- 
stants. 

6.11  if  a  soeclfle  occurrence  of  a  table. item  is  used 
repeatedly,  move  It  to  an  unsuyscrioted  data  ele¬ 
ment  and  use  that  data  element  Instead. 

6.12  Plies  should  be  opened  and. closed  Immediately  be¬ 
fore  .and  after  use.  Multiple  ooenlna  and  elosino 
of  a  file  should  be  avoided. 

6.13  in  proorams  that  use  .the  CALL  statement,  use  as 
few  data  names  as  possible  in  the  U8|NG  l|st,  A 
level  01  can  represent  all  arouments  with  Indivi¬ 
dual  . l$ems  apoearlno  as  subdefinltlons.  whleh  can 
be  initialized  as  reouired  prior  to  the  call. 

6.14  All  oroqrams  should  be  impervious  to  input  data. 

6.14.1  Check  divisors  for  a  zero  value. 

6.14.2  Ranae  cheeks  should  ye  performed  on  Jnyut 
used  as  tabif .subscripts.  The  ranae  llmjts 
should  be  defined  as  constants  in  workfno 
Btoraoe.  not  literals  becayse  table,  size 
may  ehanae  throuoh  oroaram  maintenance. 

6.14.3  Items  used  in  calculations  should  be  tested 
for  NUMERIC  and  ranae  before  use. 

6.14.4  Error  handlina  procedures  should  indicate 
the  nature  of  the  errors  that  mloht  oeeur. 

6.15  Restrict  the  use  of  COBOL  iNDEXys .any. BET  state- 

mynts  since  these  are  Inflexible  end  aav 
hinder  maintenance. 
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A8BESQ2X  A  ACfcfiOMladaasaotA 

The  need  for  cone  sort  of  standardisation  of 
COBOL  oroarams.  m  colte  of  various  orooramners  and 
their  diverse  backarounds#  provided  the  Incentive  for 
oroducina  the  COBOL  Proaramnlna  Conventions.  The  ef¬ 
fort  was  based  on  the  docunents  entitled  "Computer  op¬ 
erations  Group#  COBOL  Proaram  conventions*  (May  7# 
1980)  bv  Thomas  s.  Brinks  of  the  Price  Gilbert  Memori¬ 
al  Library .  GIT#  and  "COBOL  Proaram  Standards"  (May 
1979),  Office  of  the  Realstrar  and  ocs  Applications 
System  Oeslan#  GIT.  Suaaestions  end  corrections  were 
offered  bv  ees/cstl  associates  David  winters#  Gary 
Peckhon  and  Joe  Celko. 

This  document  was  initially  developed  under  the 
CASTS  Prolect  A-2560,  funded  bv  AIRMICS.  GIT.  These 
conventions  are  adhered  to  throuohout  the  CASTS  system 
software  in  an  effort  to  provide  consistency  and  main¬ 


tainability 
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IDENTIFICATION  DIVISION. 


PROGRAM-ID. 

AUTHOR. 

DATE-WRITTEN. 

DATE-CORPILED. 

REMARKS. 


EXAMPLE. 

DAVID  WINTERS. 
28-NAY-1980. 

NAME  REORDERING. 


*  THIS  PROGRAM  READS  FROM  THE  FILE  'INPUT'  THE 

*  NAME  TO  BE  RE-ORDERED  AND  CONVERT8  IT  TO  THE 

*  FORMAT  (LAST  NAME.  FIRST  NAME.  MIDDLE  NAME) 

*  AND  WRITES  IT  TO  FILE  "OUTPUT". 


ENVIRONMENT  DIVISION. 


CONFIGURATION  SECTION. 

SOURCE-COMPUTER.  VAX-11. 

OBJECT-COMPUTER.  VAX-11. 

INPUT-OUTPUT  SECTION. 

FILE-CONTROL. 

SELECT  NAME-FILE-IN  ASSIGN  TO  "INPUT". 
SELECT  NAME-FILE-OUT  ASSIGN  TO  "OUTPUT". 
SELECT  PRINTER  ASSIGN  TO  "PRINT". 


DATA  DIVISION. 


FILE  SECTION. 

FD  NAME-FILE-IN 

LABEL  RECORDS  ARE  OMITTED 
DATA  RECORDS  18  NAME-RECORD-IN. 

01  NAME-RECORD-IN. 

02  FIRST-NAME-IN  PIC  X(10>. 

02  MIDDLE-NAME-IN  PIC  X. 
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02  LAST-NAME-IN  PIC  X(20). 

FD  NAME-FILE-OUT 

LABEL  RECORDS  ARE  OMITTED 
DATA  RECORD  IS  NAME-RECORD-OUT. 

01  NAME-RECORD-OUT. 


02 

LAST-NAME-OUT 

PIC 

Xf  20) . 

02 

FIRST-NAME-OUT 

PIC 

XflO). 

02 

MIDDLE-NAME-OUT 

PIC 

X. 

FD  PRINTER 

LABEL  RECORDS  ARE  OMITTED 
DATA  RECORD  IS  PRINT-LINE. 

01  PRINT-LINE. 

02  FILLER  PIC  X(133). 


WORKING-STORAGE  SECTION. 

01  FILE-CONTROL -SWITCHES. 


02 

EOF 

-INPUT-SW 

PIC 

9 

VALUE 

0. 

88 

EOF 

VALUE 

1, 

88 

NOT-EOF 

VALUE 

0. 

RECORDS 

-PROCESSED-COUNTERS. 

02 

RECORDS-REAO 

PIC 

9999 

VALU2 

0. 

02 

RECORDS-WRITTEN 

PIC 

9999 

VALUE 

0. 

PRINTER 

-MESSAGES. 

02 

PROCESSED-MSG. 

03 

FILLER 

PIC 

X 

VALUE 

SPACE. 

03 

FILLER 

PIC 

XC5) 

VALUE 

•READ 

03 

RECORDS-READ-OUT 

PIC 

till. 

03 

FILLER 

PIC 

X(5) 

VALUE 

SPACES 

03 

FILLER 

PIC 

Xf  8) 

VALUE 

"WRITTEN  ", 

03 

RECORDS- WRITTEN -OUT 

PIC 

ZZZZ. 

*********************************************** ******** 
PROCEDURE  DIVISION. 


MAIN-PROGRAM  SECTION. 

000-M A IN-LINE. 

PERFORM  100-INITIALIZE-AND-OPEN. 
PERFORM  200-PROCESS-NAME-RECORDS 
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UNTIL  EOF. 

PEpFORM  3 00 -CLOSE-DOWN . 

STOP  RUN. 

100-INITXALIZE-AND-OPEN. 

OPEN  INPUT  NAME-FXlE-ip 

OUTPUT  NAME-PILE-OUT.  PRINTER. 

200-PR0CES3-NAME-RECORDS. 

PERFORM  210-READ-NAME-FILE. 

IF  NOT-EOF 

PERFORM  220-REORDER-NAMES-FILE 
PERFORM  230-UPDATE-PROCESS-COUNT. 

210-READ-NAME-FILE. 

READ  NAME-FILE-IN  AT  END 

MOVE  1  TO  EOF-INPUT-SW. 

220-REORDER-NAMES-FILE. 

MOVE  LAST-NAME-IN  TO  LAST-NAME-OU?. 

MOVE  FIRST-NAME-IN  TO  FIRST-NAME-OUT. 

MOVE  MIDDLE-NAME-IN  TO  MIDDLE -NAME-OUT. 
WRITE  NAME-RECORD-OUT. 

230-UPDATE-PROCESS-COUNT. 

ADD  1  TO  RECORDS-READ. 

ADD  1  TO  RECORDS- WRITTEN. 

300-CLOSE-DOWN. 

MOVE  PROCESSED-MSG  TO  PRINT-LINE. 

WRITE  PRINT-LINE. 

CLOSE  NAME-FILE-IN.  NAME-PILE-OUT.  PRINTER. 
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